Uncovering Anyone's True Google Workspace Email Address From An Alias

Just last month I asserted that I do not see email aliases as a security measure. They are a privacy safeguard that can help some folks obscure their identity, but even then - depending on the configuration, it could be a flimsy safeguard.

As it turns out, this assertion was somewhat validated when I discovered that you can get anyone’s true email address (Google Account) if they are hosting their email on Google Workspaces from their alias, even if the alias is not on the same domain. Before we get into that, though - let’s walk through some of the basics of email aliases in Google Workspaces.

Basics of aliases #

When a customer configures a Google Workspaces instance, they set themselves up with their custom domain. That way, because the customer is technically an “organization” (it doesn’t really matter on paper - you can use it for your personal needs too), their email is not a generic @gmail.com but rather something that is associated with their own assets, like @den.dev for me and this blog.

Every single Google Workspaces customer has a primary email - that is their email that they log into their Google assets with. This is also commonly known as the Google Account. Google Workspaces customers also have the ability to set secondary emails, or an alias for their main account.

This is convenient for several reasons. First, I can use different emails for different services so that I can sort my mail easier (and see who sells my data). Second, I can use it as a bit of a privacy guard - if instead of @den.dev I also associate a domain like @example.com or any other generic name that is not immediately linked to my identity, I can spin up aliases that I can share with, say, services that I don’t trust to keep my data safe at all. Then, instead of using [email protected] (this is the email I publicize on this blog for folks to contact me) I can just use something like [email protected]. If the email leaks - it’s not immediately clear to every data miner that it’s mine.

Anyway, this brings up the next point that I wanted to add - not only can you create aliases for your primary domain but you can also add many other domains to your Google Workspace configuration, which means that you can also create aliases for your main account that are associated with those domains.

Aliases are an interesting beast because they are not the Google Account address, so you can’t attempt to log in with them. If I have a generic [email protected] or [email protected] from somewhere, there is no way for me to go to the Google Accounts page and try to authenticate - I will get an error.

This behavior is actually consistent across providers - if you use Microsoft 365, for example, you also won’t be able to log in with an alias because that’s not actually the account email. It’s both practical and makes a ton of sense - if someone got a hold of your alias they shouldn’t be able to try and log into your main account if that’s all they have.

Getting to the true email #

Google, however, has an interesting behavior that I have not seen used with other providers, and it’s something I found when I was tinkering in a VM with Mozilla Thunderbird. While I am using Thunderbird as an example, the same behavior can be seen in other email clients, like Microsoft Outlook. This is not an email client vulnerability or oversight - this is a Google-owned behavior that is specific to aliases associated with Google Workspaces.

In Thunderbird, instead of logging in directly with the email provider right away, a user can first enter the email address they want added and have the client do service discovery for them before it puts the authentication box on the screen. This is more convenient for non-technical users because, unlike the iOS email account connection flow, this experience doesn’t ask them where they host their email - just enter the email address, the client will try to figure out which service it’s associated with, and then have the user log in.

What I noticed, however, is that if I enter [email protected], the login box will show me my true email instead of the alias:

The email address you see in the login screen is not the email address I used to add my account. As a matter of fact, I fully expected that flow to error out because I am so used to the Microsoft 365 behavior, where entering an alias will result in an error. As it turns out, Google has built an API that is capable of resolving an alias to the true email of a customer. That API has the following structure for the request endpoint:

https://accounts.google.com
  /o
  /oauth2
  /auth
    ?response_type=code
    &client_id=<REGISTERED_CLIENT_ID>
    &redirect_uri=http%3A%2F%2Flocalhost
    &scope=https%3A%2F%2Fmail.google.com%2F
    &login_hint=<alias>%40<example.com>

This API requires no authentication and can be invoked in a private session with no prior Google account connected. There are a few parameters that need to be specified, though:

What this means is that as long as you have a collection of email addresses that are hosted on Google Workspaces, you can easily verify whether they are the true email account or an alias with this API, and if they are an alias - get to the real account behind it. The alias must be valid for it to resolve to the true account. That is, if you use [email protected] and that email alias is non-existent, you will get a blank box as a result.

Will this work for any Google Workspace accounts? That is, if I am using aliases through Google Workspaces I will always have my main account exposed through those?

Not quite! There are exceptions to this behavior. For example, if there is another Single Sign-On (SSO) provider in front of the Google Workspaces instance, you get another gate that doesn’t behave the same way as Google’s default implementation. In that case, the login_hint is most likely ignored unless the SSO provider somehow pre-fills it, although I have not seen that happen.

Now, you might ask - how do you find if an account or an alias associated with a custom domain is hosted on Google Workspaces? Why, by looking at DNS records for that domain, of course! Domains that are associated with a Google Workspaces account will have MX records pointing to Google! On Windows, you can run a command like this:

nslookup -type=mx den.dev

If the lookup was successful, it will return records like this:

Server:  <SERVER_NAME>
Address:  <SERVER_ADDRESS>

Non-authoritative answer:
den.dev MX preference = 1, mail exchanger = aspmx.l.google.com
den.dev MX preference = 10, mail exchanger = aspmx2.googlemail.com
den.dev MX preference = 10, mail exchanger = aspmx3.googlemail.com
den.dev MX preference = 5, mail exchanger = alt1.aspmx.l.google.com
den.dev MX preference = 5, mail exchanger = alt2.aspmx.l.google.com

This is the first clue that the account is associated with a Google Workspaces tenant. From there, anyone can invoke the endpoint above with a known email alias (that they can collect from many sources, like the myriad of data breaches nowadays) to discover the true email behind it.

What I’ve also noticed in my testing that sometimes you can even get someone’s Gmail account this way - I am not entirely sure how that’s done since you can’t associate a personal Gmail account with a Google Workspaces email address, but it’s a funky behavior nonetheless.

I reported this to Google as a potential privacy gap, however the issue was flagged as Won't Fix (Intended behavior). They referred me to their documentation where it’s stated:

Email aliases aren’t private. Sometimes, they’re visible to other users. For example, if a recipient searches Gmail for messages from [email protected], search results might also include messages from Bill’s alias, [email protected].

This is fair - if you send and receive email with aliases, I would expect that the true email would be included in one of the headers, but if I am only using aliases to receive email for parties I don’t necessarily fully trust, then having a quick way to “uncloak” my real email seems like a privacy miss. Google disagrees, however.

Conclusion #

If you are using aliases on Google Workspaces as a privacy measure to “cloak” your main account - you can stop. They are not at all protecting your main account from being uncovered. Anyone can easily discover the real account behind an alias on Google Workspaces, even if it’s used only to receive mail.

If you are looking to use aliases as a true privacy measure, you should be looking at alternative email providers that are more strict about alias protection. Make sure that the custom domain you are using is not directly tied to your identity.

If you are using aliases in Google Workspaces as a convenience measure and you are not worried about someone discovering that [email protected] is an alias for [email protected], you are not affected by anything that I’ve described above and can carry on.

Disclosure timeline #